The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
In some network deployments, a customer network may use multiple Internet Service Provider (ISP) connections to the Internet. For each connection of the multiple ISP connections, an ISP network would typically provide a small pool of Internet Protocol (IP) addresses that may be used to overload Internet-bound traffic sent from a node in the customer network. For example, a Network Address Translation (NAT) process executing in a router at the edge of the customer network would translate (or replace) a local IP address in outbound traffic to an IP address from the pool of IP addresses assigned to the router by the ISP network. In this way, a relatively large number of nodes in the customer network can use relatively few global IP addresses that can be reached through the ISP network.
In a customer network that uses multiple ISP connections, it is usually desirable to optimize routing for performance and load-balance of inbound and outbound traffic across all available ISP connections. However, optimizing and load-balancing of inbound (or return) traffic is difficult to achieve because inbound traffic relies on a return path which is determined by the IP address assigned to the corresponding outbound traffic by the NAT at the edge of the customer network. For example, in some operational scenarios it may be necessary to change the return path for inbound traffic when load-balancing on an inbound ISP connection needs to be performed or when an inbound ISP connection experiences degrading performance because of brownouts or other network problems. However, since the return path is determined by the IP address assigned to the corresponding outbound traffic, and since the routes for reaching this IP address have already been advertised, the return path cannot be changed to an ISP connection provided by another ISP network unless the (possibly significant!) route changes are advertised to that and/or other ISP networks. In addition, if the outbound traffic includes packets carrying data for already established Transmission Control Protocol (TCP) connections, the source (return) IP address in such packets cannot be changed because such a change would cause the termination of the TCP connections.
Although the problem of optimizing return traffic paths is presented above with respect to a customer network that uses multiple ISP connections over an IP network protocol, it is noted that this problem is not unique to ISP connections or to the IP protocol. Rather, this problem may exist for any operational context that may benefit from optimized routing and load-balancing over multiple connections that carry data over any Layer 3 or Layer 2 routable protocol.